IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The architecture and general features of the IMS are described generally in 3GPP specification TS 23.002 and, in more detail, in TS 23.228. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
The IMS is logically structured into a so-called “core network” layer (implemented by functional entities which are briefly described below), and a so-called “service layer” (essentially comprising “application servers” arranged to provide services to user terminals (referred to hereinafter as User Equipment (UE)) connected via the IMS, and/or arranged to mediate in the provision of services by executing specific service-based logic, such as to divert an incoming multimedia session in certain circumstances).
Of particular interest here are the Serving Call Session Control Function (S-CSCF) and the Home Subscriber Server (HSS) which are both present within the IMS core network. The S-CSCF performs the session control services for a UE and maintains a session state according to the (SIP) signalling exchanged with a UE for supporting the services originated and/or terminated by the UE. The S-CSCF can also communicate with “application server/s” of the IMS “service layer” to handle a service for an UE. Further details of the functionality of a S-CSCF are given in chapter 4.6.3 of 3GPP specification TS 23.228. The HSS is the master database for storing data for a given user. It is the entity containing the subscription-related information to support the network nodes actually handling communications (e.g. calls, sessions, etc) with a UE registered for said user. For example, the HSS provides support to the nodes implementing Call session functionalities in order to complete the routing/roaming procedures by solving authentication, authorization, naming/addressing resolution, location dependencies, etc. Further details of the functionality of the HSS are given in chapter 4.1.1.1 of 3GPP specification TS 23.002.
It is noted that, within the IMS, a user may have one of three different registration states. These are:                “Registered”—a contactable address is registered for the user; the user has an S-CSCF allocated that maintains the user profile which allows the user to initiate and terminate telecommunication services (such as making and receiving calls).        “Not Registered”—no contactable address information is held for the user by the IMS, nor is an S-CSCF allocated to the user. The user cannot initiate or terminate services from/to any terminal (UE) since no user terminal is currently registered for the user. Therefore, no services are available for the user. The user might, however, receive a terminating service (e.g. a terminating call) which can lead—according to existing IMS procedures—to an S-CSCF being allocated to the user to keep the user profile. This allows the execution of so-called “unregistered services” (e.g. diversion to a server of a terminating service, such as diversion of an incoming voice call to a voice mail server) via the allocated S-CSCF, and changes the user status to “Unregistered” (see below description of the “Unregistered” state).        “Unregistered”—no contactable address information is held for the user (e.g. there is no IP address of a UE registered for the user which is usable to contact the user). An S-CSCF is however allocated to the user and the S-CSCF maintains the user profile. So-called “unregistered services” are available to the user. These unregistered services allow a terminating service addressed to a user to be processed when the user has no UE terminal currently registered within the IMS which can be addressed from the IMS for the terminating service. Therefore, a user profile, held by the S-CSCF, can comprise information to process a terminating call addressing an identifier of the user in such a way that it is held (i.e. terminated) by a voice mail server.        
In the event of a UE being powered off, or due to a loss of mobile network coverage, a user may be moved from a Registered to a Not Registered state. Thereafter, due, e.g. to some event such as a terminating service request, the user may be moved from the Not Registered state to the Unregistered state. To achieve this, the S-SSCF will obtain user profile data from the HSS. After some timeout period during which no further event occurs, the user will be moved back to the Unregistered state and the S-CSCF will delete the user's profile data.
Whilst the 3GPP organisation originally proposed the IMS in the context of mobile networks, it is noted that the IMS also finds application in respect of fixed access networks. A typical operator architecture may utilise the IMS to seamlessly deliver services over both a fixed and a mobile network.
The 3GPP organisation has standardized so-called “IMS Restoration Procedures” in the 3GPP specification TS 23.380 in order to specify how to handle a service interruption due to failures in the IMS core network. In particular, the specification considers the case where an S-CSCF assigned to serve a UE (after a registration of the UE) becomes unreachable, e.g. due to internal error, or looses user data, e.g. due to a restart. The restoration procedures envisaged by 3GPP allow the S-CSCF to store and retrieve registration user data such that, when a user registers successfully in the IMS network via a UE, the primarily assigned S-CSCF stores all the data needed to serve the user in the HSS. In the event of a failure of the primarily assigned S-CSCF, another (secondary) S-CSCF may retrieve the saved data and continue serving the users in a way that is transparent to the end users.
The proposed restoration procedures require both that the HSS itself, and the IP connectivity between the S-CSCF and the HSS, are continuously available. As such, there is a possibility that both temporary and permanent failures in the HSS and the interconnecting link will result in the restoration procedures failing to restore user services. To mitigate against this problem, the HSS is required not to trust user related information sent to it by S-CSCF if there is an inconsistency detected between the sent user data and the user data already stored in the HSS. The HSS, upon detecting such an inconsistency, must re-establish the old data into the S-CSCF (i.e. the so called “restoration information” which includes the old contact address, e.g. IP address, of the user corresponding to the old registration. However, this approach can result in inappropriate service delivery to the user. For example, when the user is Not Registered with the S-CSCF but is recorded as Registered in the HSS, re-registration of the user in the S-CSCF by the HSS may cause the S-CSCF to attempt to deliver a terminating service to an obsolete or even re-assigned “contact” address, rather than delivering an Unregistered service, e.g. voice mail.